allow DocumentMetadata to hold arbirtary data #158
Conversation
|
A more flexible approach would be to allow documents to hold any metadata (arbitrarily complex) and provide the mechanism for converting custom metadata to the 'standardized' Just for the record, there was a pull request extending |
|
Yes, having an abstract metadata type seems like a better idea. The API changes may be more intrusive though? Stemming depends on the language stored in metadata, that needs to be abstracted out. And there are a bunch of APIs in |
This introduces a new `custom` field in `DocumentMetadata` that is set to `nothing` by default, but can be used by user code to store arbirtary metadata against the document for use later. Having a pre-determined place to store such data would simplify processing in may cases.
|
Rebased to resolve conflicts. Probably this change will be sufficient for now? While we can continue discussing about a more appropriate metadata representation for the future. |
DocumentMetadata: generalized types of data fields
Simplifying `DocumentMetadata` constructor and providing compatibility
style fix
This introduces a new
customfield inDocumentMetadatathat is set tonothingby default, but can be used by user code to store arbirtary metadata against the document for use later. Having a pre-determined place to store such data would simplify processing in may cases.